Table des matières
Node Exporter, le collecteur de métriques systèmes
III – Rajout d’un serveur à monitorer
Gestion des alertes avec Alertmanager
VIII – Les alertes dans Grafana ?
VII – Vérification des certificats SSL
Monitoring, Métrologie, Supervision ?
Le monitoring, c’est l’art pour un administrateur de traquer ses machines, de suivre l’activité, de voir ce qui merdouille…
Bah oui, on est curieux et on veut savoir ce qui se trame…
Mais dans la notion de Monitoring, on trouve deux « types » de monitoring :
•.Métrologie : c’est tout bêtement avoir de jolis courbes qui indiquent l’usage dans le temps de différentes « choses ». Typiquement, CPU, RAM, réseau, etc…etc..
•.Supervision : c’est voir rapidement d’un coup d’œil l’état des systèmes. Typiquement, une interface avec plein de choses au vert si tout va bien…
Par chez moi, jusque la, pour la métrologie, Munin était mon ami et côté supervision, Nagios était mon … heu, j’ai jamais vraiment accroché donc on va dire que c’était un invité de passage…
Je me suis souvenu que j’avais commencé un brouillon la dessus, il y a fort fort longtemps. A cette époque, je passais de Cacti à Munin et j’essayais Centreon couplé à Nagios. Mais le brouillon commençait à sentir le fennec… et je me suis dit qu’il y avait surement mieux maintenant.
Et force est de constater qu’en effet, les vénérables ont fait leurs temps et que les solutions « modernes » sont ‘achement sexys 😉
Utilisant le Stack ELK (Elasticsearch, Logstash et Kibana) pour mes logs, je me suis imaginé tout voir dans Kibana (l’interface graphique). Mais si ELK pour la gestion des logs, c’est simplement parfait, pour les métriques, ce n’est pas la même musique.
Le type de données n’est pas le même, les outils ne sont pas vraiment adaptés…
En creusant un peu, on trouve des solutions qui ont le goût d’ELK (surtout du K en fait), mais orientés métriques et supervisions.
Les bases de données utilisées alors sont des bases TSDB (Time Serie DataBase) qui sont spécialement conçues pour du stockage de métriques.
On trouve plusieurs solutions, mais les deux qui se distinguent sont articulées autour d’ InfluxDB et de Prometheus.
InfluxDB :
•.InfluxDB : la base TSDB.
•.Telegraf : le collecteur de base qu’on installe sur les machines à surveiller.
•.Grafana : l’interface Web qui permet de se faire de jolis tableaux de bords. Clairement, ça fait penser à Kibana, mais pour les métriques.
Prometheus :
•.Prometheus : la base TSDB.
•.Node Exporter : le collecteur de base.
•.Grafana : Et oui, Grafana supporte moult sources de données.
Comparons un peu :
•.Au niveau soutien, suivi :
Prometheus semble l’emporter.
Gros plus, les Dashboards pour Grafana sont plus nombreuses (oui, on peut importer des Dashboards proposées sur le site de Grafana, et la, je ne vous dis pas le gain de temps.
Très utile également pour voir comment faire tel ou tel type de graphiques, jauges, et pour apprendre le PromQL, j’en parle plus loin)
•.Consommation de ressources :
Ça semble un poil mieux côté Prometheus (mais les deux solutions restent de toute façon très légères à côté d’un ELK et de son Java).
•.Exporters :
Dans les deux environnements, on trouve de quoi mesurer des serveurs SQL, HAProxy, Redis, du SNMP, etc.. Mais le choix est plus large côté Prometheus.
Une liste (non exhaustive) : https://prometheus.io/docs/instrumenting/exporters/
Au niveau collecteur basique pour les métriques systèmes (Telegraf pour InfluxDB et Node Exporter pour Prometheus), les deux fournissent la base, mais la aussi Node_Exporter est plus bavard.
•.Fonctionnement :
InfluxDB, c’est du PUSH. Ce sont les clients qui poussent vers le serveur.
Prometheus, c’est par défaut du PULL. C’est le serveur qui vient chercher sur les clients. Mais si besoin, on peut faire du PUSH avec l’ajout de Pushgateway (toujours par l’équipe de Prometheus). Utile par exemple en cas de firewall ou de Nat…
•.Langage :
InfluxDB, c’est du SQL quasi standard, par ex : Select mavar FROM matable…
Prometheus, c’est un langage proprio, le PromQL.
Pour avoir une variable ? Suffit juste de donner son nom. Pas de select, etc..
C’est plus « simple » même s’il faut « prendre le coup » et c’est la que les DashBoards préconçus sont pratiques car en regardant ce qu’on fait les autres, on comprend.
Pour info, la Doc de PromQL : https://prometheus.io/docs/prometheus/latest/querying/basics/
•.Cluster :
InfluxDB ne le permet pas dans sa version « gratuite », faut payer une licence… Argh…
Prometheus, c’est natif, documenté et pas compliqué à mettre en œuvre (dans les articles à venir, je ne l’aborde pas, mais j’en parlerais un jour…)
Je n’ai pas tout comparé point par point, mais vous avez déjà une petite idée des principales différences.
Et pour moi, la cause est entendue, ce sera Prometheus le vainqueur.
Pour la petite histoire, Prometheus est à la base l’outil interne de https://soundcloud.com/, lui même dérivé de l’outil interne de Google, Borgmon. Ils ont rendu le projet public et surtout open-source. Et sincèrement, ce fut une excellente idée.
Dans les articles qui suivent, les téléchargements indiqués sont les dernières versions en date au moment de la rédaction.
Pour être à jour, pensez à regarder ici : https://prometheus.io/download/ et modifiez en conséquence les différents wget que j’indique.
Attention aussi au format yml utilisé pour les fichiers de configs !
Il ne faut pas utiliser de tabulations pour indenter, mais toujours deux espaces.
Si un truc ne démarre pas, 9 chances sur 10 que le problème vienne de la.
J’ai fait le choix de le mettre sur une VM à part. Plus tard, on trouvera son IP : IP.PROMETHEUS.
On télécharge,on décompresse et on copie les exécutables :
# wget https://github.com/prometheus/prometheus/releases/download/v2.11.1/prometheus-2.11.1.linux-amd64.tar.gz
# tar xvf prometheus-2.11.1.linux-amd64.tar.gz
# cd prometheus-2.11.1.linux-amd64/
# cp prometheus /usr/local/bin/
# cp promtool /usr/local/bin/
Ensuite, on va créer les répertoires qui vont bien et faire de la copie :
# mkdir /etc/prometheus
# mkdir /var/lib/prometheus
# cp -r consoles /etc/prometheus
# cp -r console_libraries /etc/prometheus
Oui, c’est plus contraignant qu’un apt-get, mais c’est pas la mer à boire non plus 😉
Pour configurer Prometheus, on va créer un fichier /etc/prometheus/prometheus.yml et y coller ce qui suit :
global:
scrape_interval: 10s # Temps entre les releves
evaluation_interval: 30s # Temps entre l'évaluation des regles (pour les alertes)
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
rule_files:
# - "rules/alert"
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'systems'
static_configs:
- targets: ['localhost:9100']
La configuration est assez simple à comprendre.
Le scrape_interval peut être modifié par la suite pour des jobs ou des targets précises.
Pour le moment, les alertes, on laisse de côté.
Au niveau scrap_configs, il faut comprendre qu’un job correspond à un type de relevé et pour lequel on donnes les targets concernées.
Le job « prometheus » sert pour les relevés propres au serveur Prometheus.
Le job que j’ai appelé « systems » (mais vous pourriez le nommer toto par exemple) récupère les métriques systemes fournies par Node Exporter( que l’on installera juste après)
De la lecture ici : https://github.com/prometheus/prometheus
Et pendant que j’y suis, pour les acharnés, il est bien sur possible de ne pas prendre les binaires mais de compiler soit même.
Mais bon, perso, je simplifie au maximum pour les tutos (pour laisser le temps à d’autres explications… 😉 )
Prometheus offre une interface web simple dont je parle plus bas. Je veux l’avoir à disposition sur une URL du genre : https://sous.mondomaine.fr/prometheus/
La configuration du reverse, dans Nginx, dans le block server sous.mondomaine.fr :
location /prometheus/ {
proxy_pass http://IP.PROMETHEUS:9090/;
proxy_http_version 1.1;
}
Et on pensera à recharger Nginx.
Avant de mettre ça « au propre », on va tester :
# prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries
Pour voir les flags disponible :
# prometheus -h
Bien sur, plus d’infos ici : https://github.com/prometheus/prometheus et la : https://prometheus.io
Maintenant, ne reste plus qu’à couper (CTRL-C) puis à faire un p’tit service pour ne pas avoir à faire de screen ou autres cochonneries.
On rajoute l’utilisateur dédié, puis on lui colle les droits :
# useradd --no-create-home --shell /bin/false prometheus
# chown prometheus:prometheus /etc/prometheus/ -R
# chown prometheus:prometheus /var/lib/prometheus/ -R
# chown prometheus:prometheus /usr/local/bin/prometheus
# chown prometheus:prometheus /usr/local/bin/promtool
Ensuite on va créer un fichier /etc/systemd/system/prometheus.service et y mettre :
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target
[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
--config.file /etc/prometheus/prometheus.yml \
--storage.tsdb.path /var/lib/prometheus/ \
--web.console.templates=/etc/prometheus/consoles \
--web.console.libraries=/etc/prometheus/console_libraries \
--web.external-url=https://sous.mondomaine.fr/prometheus/ \
--web.enable-lifecycle \
--web.route-prefix="/" \
--storage.tsdb.retention.time 90d
[Install]
WantedBy=multi-user.target
Vous remarquerez que j’ajoute quatre flags :
web.enable-lifecycle permet de recharger la config de prometheus avec la commande :
# curl -X POST http://localhost:9090/-/reload
web.external-url indique quand à lui l’adresse utilisé pour accéder à l’interface depuis l’exterieur (du coup, pensez à le changer).
web.route-prefix= »/ » indique que les chemins en interne restent sur / et non pas sur /prometheus/.
storage.tsdb.retention.time 90d modifie le temps de rétention des données qui par défaut est de 15 jours.
Et pour terminer :
# systemctl daemon-reload
# systemctl enable prometheus.service
# service prometheus start
Et pour voir si c’est bon :
# service prometheus status
Impeccable, c’est en place très rapidement.
On peut enlever ce qui peut l’être :
# cd
# rm prometheus-2.11.1.linux-amd64 -r
# rm prometheus-2.11.1.linux-amd64.tar.gz
Prometheus offre une interface web de base. Avant d’aller plus loin, voyons ce qu’elle propose et c’est donc sur l’adresse https://sous.mondomaine.fr/prometheus/.
Par défaut, on arrive sur l’éditeur de requêtes. Dans le champ, tapez « prom » et vous allez voir les métriques internes de Prometheus à disposition.
Par ex : prometheus_tsdb_head_chunks, puis exécutez et voyez le retour. Mais on reviendra sur les requêtes plus tard quand on installera Grafana.
Dans le menu Status puis Targets, on peut voir une sonde Ok et l’autre Down. La Down est celle de Node_Exporter, ce qui est logique vu qu’on ne l’a pas encore installé.
L’interface nous permettra aussi de voir les alertes, mais on en parlera plus tard.
Voila, Prometheus est en place et vous le constatez, ce n’est pas compliqué.
Dans la partie suivante, nous allons mettre en place Node Explorer, le collecteur de métriques systèmes.
Il va nous permettre d’avoir nos métriques systèmes à disposition. Cpu, Ram, Espace Disque et quantités d’informations bientôt à votre portée !
Classique :
# cd
# wget https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz
# tar xvf node_exporter-0.18.1.linux-amd64.tar.gz
# cd node_exporter-0.18.1.linux-amd64/
# cp node_exporter /usr/local/bin/
Oui, un air de déjà vu…
Node Exporter n’a pas besoin de fichier de config, il suffit juste de le lancer.
Ceci dit, vous pouvez jeter un œil la : https://github.com/prometheus/node_exporter et constater que par défaut, beaucoup de choses sont activées.
On peut les désactiver en passant l’argument –no-collector.<name>. Par ex : –no-collector.zfs.
Au contraire, d’autres sondes sont désactivées, on peut alors les activer avec –collector.<name>.
On lance avec, par exemple :
# node_exporter --no-collector.zfs --no-collector.pressure
A vous d’affiner ce qu’il vous faut ou non.
Ça se lance ? Parfait, alors on met ça en service.
La routine :
# useradd --no-create-home --shell /bin/false node_exporter
# chown node_exporter:node_exporter /usr/local/bin/node_exporter
On créer le fichier /etc/systemd/system/node_exporter.service :
[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target
[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter \
--no-collector.zfs \
--no-collector.pressure
[Install]
WantedBy=multi-user.target
Et ensuite :
# systemctl daemon-reload
# systemctl enable node_exporter.service
# service node_exporter start
Puis :
# service node_exporter status
# cd
# rm node_exporter-0.18.1.linux-amd64 -r
# rm node_exporter-0.18.1.linux-amd64.tar.gz
La configuration dans Prometheus est déjà en place. Pour mémoire, dans le fichier /etc/prometheus/prometheus.yml :
- job_name: 'systems'
static_configs:
- targets: ['localhost:9100']
Il suffit ensuite d’aller voir dans son interface Web, et la target doit être Up.
Pour rajouter un serveur, rien de compliqué.
Vous installez Node Exporter comme on vient de le faire.
Puis dans la configuration de Prometheus, dans le fichier /etc/prometheus/prometheus.yml vous rajoutez la nouvelle target dans le job dédié à Node Exporter. Par exemple :
scrape_configs:
[...]
- job_name: 'systems'
static_configs:
- targets: ['localhost:9100','monautreserveur:9100']
On peut aussi tout à fait créer un nouveau job si besoin est. Et l’on peut aussi filtrer les métriques :
scrape_configs:
[...]
- job_name: 'newjob'
static_configs:
- targets: ['montruc:9100']
params:
collect[]:
- nfs
- nfsd
Pour le nommage du serveur, avoir un DNS est pratique, car si vous donnez des IPS, ce sont ces dernières qui apparaitront comme label.
Je reviendrais cependant sur ce point plus tard. Et si vous n’avez pas de DNS, suivez le guide alors…
Puis pour terminer, on recharge :
# curl -X POST http://localhost:9090/-/reload
et la nouvelle target apparait bien dans l’interface web.
On peut déjà tester avec curl :
# curl -s "monautreserveur:9100/metrics"
Et l’on voit toutes les métriques.
Ensuite, dans l’interface Web de Prometheus, on peut tester une requête, par exemple : node_cpu_seconds_total, et l’on obtient la métrique sur l’ensemble des serveurs surveillés.
Pour voir une machine en particulier : node_cpu_seconds_total{instance= »monautreserveur:9100″}
Ici, l’important est de voir que ça fonctionne, on reviendra sur les requêtes dans Grafana.
La aussi, très rapide à mettre en place et pas compliqué pour un sous.
Et pour visualiser tout cela au mieux, nous allons maintenant passer à l’installation de Grafana pour exploiter aux mieux ces nouvelles données et se faire de jolies Dashboards avec plein de jolies courbes !
mettre en place l’interface Web Grafana qui va nous permettre de mettre en place nos Dahsboards de Supervision, Monitoring, etc.
Sur la machine dédiée à Grafana, on revient à du classique apt-get :
# apt-get install apt-transport-https curl
# curl https://packages.grafana.com/gpg.key | apt-key add -
# echo 'deb https://packages.grafana.com/oss/deb stable main' > /etc/apt/sources.list.d/grafana.list
# apt-get update
Et on installe bêtement avec :
# apt-get install grafana
Comme recommandé, on exécute :
# systemctl daemon-reload
# systemctl enable grafana-server
La configuration de Grafana se passe dans le fichier /etc/grafana/grafana.ini où l’on va modifier :
domain = sous.mondomaine.fr
root_url = %(protocol)s://%(domain)s/grafana/
Au niveau de l’adresse d’accès, je veux quelques chose comme https://sous.mondomaine.fr/grafana/.
Si vous avez une erreur 404 au chargement de l’interface, plus bas, éditez de la sorte:
[auth.basic]
enabled = false
Une fois configuré, on va lancer le service :
# service grafana start
Et un p’tit :
# service grafana status
pour être sûr.
La configuration du reverse (Nginx) dans le block server sous.mondomaine.fr :
location /grafana/ {
proxy_pass http://IP.GRAFANA:3000/;
proxy_http_version 1.1;
}
On pense à le recharger au passage.
On se connecte sur https://sous.mondomaine.fr/grafana/. Le couple login/mdp par défaut est admin/admin et il vous sera demandé de modifier le mot de passe.
Pour info, Grafana supporte Openldap et autres backends pour l’authentification (on verra ça quand j’aurais le temps).
Une fois authentifié, Grafana va vous demander une source de données.
Tout simplement, vous lui dites que c’est Prometheus, que l’adresse est http://IP.PROMETHEUS:9090 et … c’est tout. Les paramètres par défauts sont bons, rien d’autre à régler.
On sauvegarde et tout doit être OK.
Ensuite, Grafana vous invite à créer votre première Dashboard.
Une fois celle ci créée, regardez en haut à droite, et voyez la série de boutons. Le premier est très utile vu qu’il permet de créer des panels.
Vous choisissez alors l’option Add Query. Puis dans la partie Query, commencez à taper node … et … la magie de l’autocomplétion !
On l’avait aussi dans l’interface web de Prometheus, mais celle ci ne marche que pour le noms de métriques. Dans Grafana, ça marche aussi pour le reste….
On va faire par exemple :
node_load1
ce qui nous affiche tous les loads sur 1 minutes de tous les serveurs.
On peut filtrer avec :
node_load1{instance="monautreserveur:9100"}
Et si par exemple vous aviez cette métrique sur plusieurs jobs, vous pourriez faire :
node_load1{instance="monautreserveur:9100",job="lejobquejefiltre"}
En gros, notre requête PromQL donnerait en InfluxDB :
SELECT node_load1 FROM matable WHERE (instance="monautreserveur:9100" AND job="lejobquejefiltre")
Bien évidement, ce n’est qu’un minuscule aperçu des possibilités… mais si vous avez compris ça, c’est 90% du PromQL… Bon ,j’exagère p’tet un poil…
Mais après, le type d’opérations (sum, count, etc..) cela reste plus ou moins la même chose d’une base à l’autre…
La doc pour mémoire : https://prometheus.io/docs/prometheus/latest/querying/basics/
Au niveau Graphique, idem les possibilités sont très nombreuses, à vous d’explorer !
Mais pour bien appréhender tout cela, il y a une méthode bien plus « pratique » et l’on va voir ça de suite !
Grafana dispose également d’un mode « Explore » (la boussole à gauche).
A la manière d’un Kibana, cela permet de préparer les requêtes et d’ajouter des filtres de façon dynamiques. Tres pratique car l’autocomplétion est complète (pas besoin par ex de taper ins.. pour avoir instance…)
De plus, une aide en ligne est dispo pour les fonctions.
Bref, c’est le bon endroit pour commencer à travailler ses requêtes avant d’en faire un panel.
Une fonction de Grafana qui, a priori ne paye pas de mine, mais pourtant se révèle être une excellente idée est la possibilité d’importer des Dashboards déjà conçues.
Et pour se mettre au PromQL, c’est fichtrement formateur de regarder des exemples concrets.
Dans Grafana, sélectionnez le bouton + à gauche, puis Import. Il suffit de rentrer l’id de la Dahsboard que l’on trouvera ici : https://grafana.com/grafana/dashboards
On peut commencer par deux Dashboards comparables (à vous de voir celle que vous préférez) et qui sont dédiées au serveur Prometheus lui même :
https://grafana.com/grafana/dashboards/3662 et https://grafana.com/grafana/dashboards/2
Une fois importée(s) (on colle l’id, on renomme si on veut et on déclare la source Prometheus) et la Dashboard chargée, on peut admirer !
Bon, c’est pas tout, mais il y a une Dashboard qui est très utile, c’est : Node Exporter Full disponible ici https://grafana.com/grafana/dashboards/1860
Elle va nous permettre de visualiser toutes les métriques remontées par Node Exporter.
Importez la, et choisissez le serveur dans Host en haut…
C’est beau hein !
Maintenant, libre à vous de regarder comment chaque panel est fait (petite flèche à côté du nom, puis Edit).
Bon, c’est bien joli tout ça, mais admettons que vous souhaitiez vous faire votre propre Dashboard avec, par exemple, l’espace disque disponible et ce pour chaque machine.
Vu que les panels de Node Exporter Full sont très bien fait, ce sera une excellente base de départ et plutôt que de copier les requêtes, puis refaire le graphique avec les options qui vont bien, etc…, il existe une option « magique ».
Dans le Dashboard Node Exporter Full, trouvez le panel Filesystem Detail / Filesystem space available.
A côté du titre, cliquez sur la flèche puis More et Copy (il arrive que cela ne s’affiche pas, cliquez alors ailleurs et recommencez).
Ensuite, allez sur votre Dashboard, créez un nouveau Panel et une option apparait : paste copied panel.
Vous cliquez le cœur plein d’espoir… Et la : No data points.
Pas de panique, c’est normal !
Éditez le panel et regardez la requête A (la seule active d’ailleurs, on peut retirer les autres avec la petite corbeille) :
node_filesystem_avail_bytes{instance=~"$node:$port",job=~"$job",device!~'rootfs'}
Des variables sont attendues. Celles ci sont celles fournies par les box de sélection en haut de la Dashboard Node Exporter Full (vous pouvez d’ailleurs voir comment ils sont fait dans les options de la Dashboard).
Bref, on va modifier en :
node_filesystem_avail_bytes{instance="monautreserveur:9100"}
Le job ne sert à rien vu que c’est toujours le même et le device, on peut l’enlever aussi pour le moment.
Maintenant, il y a quelque chose qui me chagrine, c’est qu’il montre tous les points de montage.
Alors, pour y voir plus clair, on va supprimer la légende juste en dessous : {{mountpoint}} – Available et la, on voit les métriques au complet dans la légende. Par exemple :
node_filesystem_avail_bytes{device="/dev/xvda2",fstype="ext4",instance="monautreserveur:9100",job="systems",mountpoint="/"}
Bon, bah du coup, on va simplifier et notre requête sera :
node_filesystem_avail_bytes{instance="admin:9100",mountpoint="/"}
Simple non ?
Ensuite, il suffit de répéter pour chaque serveur en dupliquant et en modifiant…
A vous les Dashboards customisées !
Je pense qu’il est possible de se faciliter la vie en préparant un gabarit, puis en exportant le Json, en le tripatouillant, et en le réimportant. Mais je verrais ça quand j’aurais le temps…
Pour le momen, nous n’avons parlé que des deux familles de métriques que nous remontons pour le moment, celle de Prometheus (préfixées : prometheus_), et les métriques systèmes via Node Exporter (préfixées : node_).
Par la suite, on verra comment monitorer d’autres services et la aussi, des Dashboards préconçues existent.
Voila pour cette petite introduction sur Grafana. Je ne fais qu’effleurer, mais Grafana est facile à comprendre et le langage PromQL se maitrise rapidement, d’autant plus que les panels déjà existant de Node Exporter Full sont très riches d’enseignements.
La documentation de Grafana est ici https://grafana.com/docs, je vous invite à aller voir.
Je vous ai donné les clés, à vous d’ouvrir toutes les portes …
Ceci dit, on reparlera de Grafana un peu plus tard, mais en attendant, on va maintenant se poser la question de « Comment savoir que tel service est down sans avoir le nez sur le monitoring ? » dans l’article dédié à l’Alerting avec Alertmanager.
Pour bien comprendre : Alertmanager se nourrit de alertes (remontées par Prometheus) et dit quoi en faire.
Il est possible d’avoir différents groupes, pour différents types d’alertes, pour avoir, par exemple, les truc vraiment urgent par SMS, etc…
Les règles d’alertes se configurent côté Prometheus.
Ici, on va rester simple et n’avoir qu’un groupe et faire du mail.
Alertmanager sera ici installé sur le même serveur que Prometheus.
Et c’est reparti :
# cd
# wget https://github.com/prometheus/alertmanager/releases/download/v0.18.0/alertmanager-0.18.0.linux-amd64.tar.gz
# tar xvf alertmanager-0.18.0.linux-amd64.tar.gz
# cd alertmanager-0.18.0.linux-amd64/
# cp alertmanager /usr/local/bin/
# cp amtool /usr/local/bin/
Puis :
# mkdir /etc/alertmanager
# mkdir /var/lib/alertmanager
La configuration se passe dans le fichier /etc/alertmanager/alertmanager.yml :
global:
smtp_smarthost: 'IP.SERVEURMAIL'
smtp_from: 'alertmanager@mondomaine.fr'
smtp_require_tls: false #optionnel, mais mon smtp interne est en clair, le tls n'étant que pour l'exterieur
route:
receiver: 'alert-mails'
group_wait: 30s
group_interval: 1m
repeat_interval: 30m
receivers:
- name: 'alert-mails'
email_configs:
- to: 'moi@mondomaine.fr'
Je reviens quand même rapidement sur la notion de groupes :
Quand une alerte est déclenchée, elle fait partie d’un groupe.
La, group_wait stipule le temps d’attente pour voir si une autre alerte du même groupe se pointe éventuellement, ceci pour tout envoyer ensemble.
Si une nouvelle alerte du même groupe se présente, c’est group_interval qui va définir le temps entre chaque « batch ».
Et repeat_interval définit le temps de réémission de l’alerte si elle est toujours en cours.
On peut aussi les grouper par label avec par exemple :
group_by: ['instance']
qui permettra de grouper tout les alertes d’une instance.
Il est possible de faire en fonction de match, de regex…
Bref, de la lecture ici : https://github.com/prometheus/alertmanager et la https://prometheus.io/docs/alerting/configuration/
Et si vous voulez bien gérer le routing, un petit outil pratique :
https://prometheus.io/webtools/alerting/routing-tree-editor/
De la même façon que pour Prometheus, on peut recharger la configuration avec :
# curl -X POST http://localhost:9093/-/reload
Alertmanager dispose lui aussi d’une interface Web, et ce coup ci, ce sera https//sous.mondomaine.fr/alertmanager/
Précision : cette interface ne remonte que les alertes en cours (celles que Prometheus lui a envoyées).
Bref, pour Nginx, classique :
location /alertmanager/ {
proxy_pass http://10.20.1.231:9093/;
proxy_http_version 1.1;
}
et on…. recharge, c’est bien, vous suivez…
# alertmanager --config.file /etc/alertmanager/alertmanager.yml --storage.path /var/lib/alertmanager/
La aussi, RAS, donc on passe en service.
On fait ce qu’il faut :
# useradd --no-create-home --shell /bin/false alertmanager
# chown alertmanager:alertmanager /etc/alertmanager/ -R
# chown alertmanager:alertmanager /var/lib/alertmanager/ -R
# chown alertmanager:alertmanager /usr/local/bin/alertmanager
# chown alertmanager:alertmanager /usr/local/bin/amtool
Puis le fichier de service /etc/systemd/system/alertmanager.service :
[Unit]
Description=AlertManager
Wants=network-online.target
After=network-online.target
[Service]
User=alertmanager
Group=alertmanager
Type=simple
ExecStart=/usr/local/bin/alertmanager \
--config.file /etc/alertmanager/alertmanager.yml \
--storage.path /var/lib/alertmanager/ \
--web.external-url=https://sous.mondomaine.fr/alertmanager/ \
--web.route-prefix="/"
[Install]
WantedBy=multi-user.target
La aussi, j’ai ajouté les deux flags web.external-url et web.route-prefix.
Et pour finir :
# systemctl daemon-reload
# systemctl enable alertmanager.service
# service alertmanager start
Puis :
# service alertmanager status
# cd
# rm alertmanager-0.18.0.linux-amd64 -r
# rm alertmanager-0.18.0.linux-amd64.tar.gz
La première chose à faire est déjà de s’assurer que l’envoi des alertes fonctionne correctement.
Une fois de plus, on va « Curler » avec :
# curl -H "Content-Type: application/json" -d '[{"labels":{"alertname":"Test"}}]' localhost:9093/api/v1/alerts
C’est d’ailleurs de cette façon que Prometheus déclenchera Alertmanager.
Et peu de temps après, un p’tit mail doit arriver.
On va connecter Prometheus et Alertmanager dans /etc/prometheus/prometheus.yml, où l’on va modifier la partie alerting et la partie rules:
alerting:
alertmanagers:
- static_configs:
- targets:
- localhost:9093
scheme: http
timeout: 10s
rule_files:
- 'rules/*'
Je pense que des explications seront superflues…
Et on recharge Prometheus :
# curl -X POST http://localhost:9090/-/reload
On va d’abord créer un répertoire pour les accueillir :
# mkdir /etc/prometheus/rules
Puis dans ce répertoire, un fichier alerts.yml ou n’importe quel autre nom… :
groups:
- name: toto
rules:
- alert: InstanceDown
expr: up == 0
for: 1m
labels:
severity: critical
annotations:
summary: "L'instance {{ $labels.instance }} est down"
description: "Le Job: {{ $labels.job }} signale que {{ $labels.instance}} est down depuis deja 1 minute. Tu attends quoi ?"
- alert: DiskFull
expr: node_filesystem_free_bytes{mountpoint ="/stockage",instance="serveurparticulier:9100"} / 1024 / 1024 / 1024 < 20
for: 1m
labels:
severity: warning
annotations:
summary: "Et zut, on arrive a moins de 20Go sur {{ $labels.instance }}"
description: "Il reste precisement {{ $value }}"
Dans ce fichier, deux alertes simples pour l’exemple. On peut en mettre autant qu’on veut. Ce que je fait, à titre personnel, c’est un fichier par groupe.
Pour le groupe, rien de sorcier, on lui donne un nom et ensuite les alertes associées.
Pour les alertes, chaque fois la même structure :
•.Le nom de l’alerte, sans espace.
•.L’expression sur laquelle filtrer. Pour la première, c’est simple. Pour la seconde, je filtre sur un serveur en particulier et l’alerte se déclenche si le résultat est inférieur à 20.
•.For indique pendant combien de temps la condition doit être remplies pour que l’alerte soit déclenchées. Elle est Pending pendant ce laps de temps.
•.Ensuite, on peut rajouter des labels.
•.Puis le contenu ou il est possible de reprendre les variables.
On peut vérifier le fichier avec :
# promtool check rules /etc/prometheus/rules/alerts.yml
promtool a été copié avec l’exécutable prometheus dans la partie I si vous avez bien suivi …
On peut remettre les permissions :
# chown prometheus:prometheus /etc/prometheus/ -R
Puis on recharge Prometheus :
# curl -X POST http://localhost:9090/-/reload
Envie d’idée pour de nouvelles règles ?
Allez voir par la : https://awesome-prometheus-alerts.grep.to/rules.html
Il n’y a plus qu’à tester et rien de plus simple !
Coupons Node Exporter sur une machine ou il est installé.
# service node_exporter stop
On attend quelques instants et dans l’interface de Prometheus https//sous.mondomaine.fr/prometheus/, dans la section Alerts, on doit voir l’alerte passer en orange (et le détail indique Pending)
Puis, une fois le délai for dépassé, elle passe en rouge (Firing) et est transmise à Alertmanager. Elle sera visible dans l’interface https//sous.mondomaine.fr/alertmanager/ et on reçoit le mail également.
Oui, c’est possible !
Il faut au préalable installer un plugin Grafana. Les plugins sont disponibles ici : https://grafana.com/grafana/plugins
Et pour l’installer, sur la machine ou est installé grafana :
# grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource
# service grafana restart
On retourne dans Grafana, on ajoute une source de données : Configuration, Data Sources, Add data sources.
Puis : Prometheus AlertManager.
Dans la config : http://IP.ALERTEMANAGER:9093 et le reste par défaut.
Une fois enregistré, faites un nouveau panel et une nouvelle requête.
A côté de Query est indiqué default (qui est la base prometheus). Et bien, tout simplement, vous allez choisir prometheus-alertmanager.
Passez le graphique en mode tableau… et rien….
Il faut en effet rajouter une légende pour que cela fonctionne.
Autre petit bug, la severity n’apparait pas,bien qu’on puisse filtrer dessus dans la requête avec par exemple : severity= »critical ». On peut bien évidement filtrer sur les champs que l’on veut.
Et pour n’afficher que certaines colonnes, c’est dans Labels avec par exemple : alertname, instance, description
Après, on peut mettre en couleur, faire des seuils, etc…
Pour en savoir plus, c’est ici : https://grafana.com/grafana/plugins/camptocamp-prometheus-alertmanager-datasource
Ha, et je viens de voir qu’il existe un dashboard : https://grafana.com/grafana/dashboards/8010
A vous de tester !
Une fois de plus, rien de bien sorcier au final. C’est rapidement mis en place, facile à comprendre et donc facile à mettre en production.
Avec tout ce qu’on a installé jusque la, on a déjà de quoi bien s’amuser. Mais il est encore des choses dont je veux vous parler…
Et pour commencer, on va causer de Blackbox, la sonde « boite noire » …
Nous allons mettre en place Blackbox Exporter, un outil permettant de faire du monitoring en « boite noire ».
Les sondes sont « externes » au système à monitorer et se contente de vérifications qu’un utilisateur lambda pourrait faire à la main. C’est en quelque sorte le contraire du monitoring en boite blanche (ce que fait Node Exporter), où l’on accède à toutes les métriques du serveur directement.
Blackbox Exporter permet d’utiliser quatre types de sondes (probe) : ICMP, HTTP(s), DNS et TCP.
Ici, il sera installé sur le serveur Prometheus. On pensera éventuellement à ouvrir les ports sur le FW si besoin.
La routine :
# wget https://github.com/prometheus/blackbox_exporter/releases/download/v0.14.0/blackbox_exporter-0.14.0.linux-amd64.tar.gz
# tar xvf blackbox_exporter-0.14.0.linux-amd64.tar.gz
# cd blackbox_exporter-0.14.0.linux-amd64.tar.gz/
# cp blackbox_exporter /usr/local/bin/
# mkdir /etc/blackbox_exporter
Pour la configuration, cela se passe dans /etc/blackbox_exporter/blackbox.yml :
modules:
http_check:
prober: http
timeout: 5s
http:
valid_status_codes: [] # par defaut, 2XX
method: GET
fail_if_body_matches_regexp:
- "Erreur lors de la connexion"
icmp_check:
prober: icmp
timeout: 5s
icmp:
preferred_ip_protocol: ip4
dns_check_soa:
prober: dns
timeout: 5s
dns:
preferred_ip_protocol: ip4
query_name: "debugo.fr"
query_type: "SOA"
smtp_check:
prober: tcp
timeout: 5s
tcp:
preferred_ip_protocol: "ip4"
query_response:
- expect: "^220 ([^ ]+) ESMTP (.+)$"
- send: "EHLO ProberCheck"
- expect: "^250-STARTTLS"
- send: "STARTTLS"
- expect: "^220"
- starttls: true
- send: "EHLO ProberCheck"
- expect: "^250-AUTH"
- send: "QUIT"
imap_check:
prober: tcp
timeout: 5s
tcp:
tls: true
preferred_ip_protocol: "ip4"
query_response:
- expect: "CAPABILITY IMAP4rev1"
- send: "QUIT"
Un module correspond à un ensemble de paramètres que vous allez configurer et qui définissent les « options » du prober choisi.
Pour l’exemple, j’ai en fait un avec chaque probe (sauf Tcp ou je l’utilise deux fois).
Pour chaque module, on trouve son nom (http_check, icmp_check,etc…), la probe utilisée (http,icmp,dns ou tcp) et la configuration associée.
Http : l’astuce consiste ici a faire échouer la sonde si le message « Erreur lors de la connexion » est présent.
En effet, si mon WordPress ne communique plus avec la base, pour la probe, on reçoit bien le code HTTP 200, mais pour autant, le site ne fonctionne pas.
Icmp : on force juste en IPv4.
Dns : le check va simplement vérifier le champ SOA.
Par exemple pour regarde si la propagation DNS est correcte en interrogeant votre serveur autoritaire et d’autres et en comparant les réponses.
On peut bien évidement interroger d’autres champs, regarder les réponses, etc…
Tcp : surement le module le plus intéressant, celui ci va nous permettre d’établir une connexion sur un service et de vérifier les réponses.
Ici, je m’en sers pour vérifier deux serveur : SMTP et IMAP. Le ping n’est pas suffisant pour cela, la machine peut encore tourner et Postfix et/ou Dovecot peuvent être dans les choux
Rien de sorcier, on donne des commandes, on regarde les retours.
Pour l’imap, comme je fais du Imaps et non pas du imap puis ensuite du ssl…, la configuration active le tls des le début de la connexion.
Envie d’ailleurs de monter votre serveur mail complet ? Je vous invite à regarder la série de tutoriels (oui, je me fais de la pub…)
Libre à vous d’imaginer des sondes pour des serveurs IRC, SSH, LDAP, etc…
Pour plus d’infos : https://github.com/prometheus/blackbox_exporter et un exemple assez complet : https://github.com/prometheus/blackbox_exporter/blob/master/example.yml
Pour recharger BlackBox en cas de modification de la configuration :
# curl -X POST http://localhost:9115/-/reload
Le ping pose un petit soucis de droit si blackbox n’est pas executé en root.
Ça se règle simplement avec :
# apt-get install libcap2-bin
# setcap cap_net_raw+ep /usr/local/binblackbox_exporter
Et on peut vérifier avec
# getcap /usr/local/binblackbox_exporter
A priori, on peut aussi ajouter ce qui suit dans le fichier de service :
[Service]
User=...
Group=...
AmbientCapabilities=CAP_NET_RAW
Bref, peu importe mais faite un truc 😉
On teste :
# blackbox_exporter --config.file /etc/blackbox_exporter/blackbox.yml
Ras, ça se lance.
Encore la routine :
# useradd --no-create-home --shell /bin/false blackbox_exporter
# chown blackbox_exporter:blackbox_exporter /etc/blackbox_exporter/ -R
# chown blackbox_exporter:blackbox_exporter /usr/local/bin/blackbox_exporter
Puis un fichier /etc/systemd/system/blackbox_exporter.service :
[Unit]
Description=Blackbox Exporter
Wants=network-online.target
After=network-online.target
[Service]
User=blackbox_exporter
Group=blackbox_exporter
Type=simple
ExecStart=/usr/local/bin/blackbox_exporter \
--config.file /etc/blackbox_exporter/blackbox.yml
[Install]
WantedBy=multi-user.target
Et pour terminer :
# systemctl daemon-reload
# systemctl enable blackbox_exporter.service
# service blackbox_exporter start
Puis :
# service blackbox_exporter status
# cd
# rm blackbox_exporter-0.14.0.linux-amd64 -r
# rm blackbox_exporter-0.14.0.linux-amd64.tar.gz
On va tester :
# curl -s "localhost:9115/probe?module=http_check&target=https://mondomaine.fr"
Et comme c’est bavard, on peut faire :
# curl -s "localhost:9115/probe?module=http_check&target=https://mondomaine.fr" | grep -v \#
Et l’on observe toutes les informations relevées par la sonde.
Pour les autres modules :
# curl -s "localhost:9115/probe?module=dns_check&target=XXX.XXX.XXX.XXX" | grep -v \#
# curl -s "localhost:9115/probe?module=smtp_check&target=XXX.XXX.XXX.XXX:25" | grep -v \#
# curl -s "localhost:9115/probe?module=imap_check&target=XXX.XXX.XXX.XXX:993" | grep -v \#
# curl -s "localhost:9115/probe?module=icmp_check&target=XXX.XXX.XXX.XXX" | grep -v \#
On peut activer le debug (dont je parlais plus haut) avec :
# curl -s "localhost:9115/probe?debug=true&module=http_check&target=https://mondomaine.fr"
On va maintenant créer les jobs correspondants dans Prometheus.
Dans la partie scrape_configs du fichier /etc/prometheus/prometheus.yml :
scrape_configs:
[...]
- job_name: 'CheckUrl'
metrics_path: /probe
params:
module: [http_check]
static_configs:
- targets:
- https://mondomaine.fr
- https://monautredomaine.fr
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: localhost:9115
- job_name: 'Ping'
metrics_path: /probe
params:
module: [icmp_check]
static_configs:
- targets:
- XXX.XXX.XXX.XXX
- YYY.YYY.YYY.YYY
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: localhost:9115
- job_name: 'SMTP'
metrics_path: /probe
params:
module: [smtp_check]
scrape_interval: 60s
static_configs:
- targets:
- smtp.mondomaine.fr:25
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: localhost:9115
- job_name: 'DNS'
metrics_path: /probe
params:
module: [dns_check_soa]
static_configs:
- targets:
- XXX.XXX.XXX.XXX
- 8.8.4.4
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: localhost:9115
- job_name: 'IMAP'
metrics_path: /probe
params:
module: [imap_check]
scrape_interval: 60s
static_configs:
- targets:
- imap.mondomaine.fr:993
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: localhost:9115
Pensez à remplacer les URLs et les IPs. et bien évidement, vous pouvez en mettre autant que desirés.
Pour les modules qui utilisent la probe TCP (smtp_checl et imap_check), il faut penser à indiquer le port.
Vous remarquerez aussi que pour ces deux la, je change le temps de scrap pour ne le faire qu’une fois par minute.
Le relabelling permet de garder les choses aux propres.
On recharge Prometheus :
# curl -X POST http://localhost:9090/-/reload
Attention, pour les checks croisant des certificats en chemin : si vos certificats sont enregistrés pour un FQDN (typiquement ceux de Let’s Encrypt) , renseigner l’IP conduira à une erreur :
msg= »TLS Handshake (client) failed » err= »x509: cannot validate certificate for XXX.XXX.XXX.XXX because it doesn’t contain any IP SANs »
On peut toujours rajouter cela dans la configuration de Black Exporter :
tcp:
tls: true
tls_config:
insecure_skip_verify: true
preferred_ip_protocol: "ip4"
Ce qui permettra de passer par l’IP. Mais on passerait à coté d’un éventuel autre probleme de certificat.
Il faut donc mieux passer par le FQDN……. Ce qui peut conduire à un autre problème si la machine qui héberge le service externe (proxy web par exemple) est sur le même réseau que votre machine qui va sonder.
En effet, au niveau du routeur, il va être embêté. Que faire de ces paquets à destination de son IP externe mais en provenance de l’interne ?
La solution : il faut mettre en place le Nat Loopback.
Passons ensuite dans l’interface Web de Prometheus.
Tout d’abord, dans Status/Targets, on peut voir nos nouvelles entrées et tout doit être Up.
Puis dans la partie Graph, on peut lancer par exemple :
probe_success
On obtient alors le retour de cette métrique pour chaque sonde.
La, on va pouvoir se faire de jolis Dashboards avec plein de choses vertes 😉
Je donne juste un exemple :
Dans Grafana, créez un nouveau Dashboard, puis Add Query.
Ajoutez cette requête:
probe_success{job="CheckUrls",instance="https://mondomaine.fr"}
Puis dans Visualization, remplacez Graph par SingleStat.
Dans la partie Coloring, activez le Background, Thresholds réglé à 0,1.
Dans Colors, cliquez Invert.
Et pour terminer, dans Value Mappings, indiquez pour 0 : Oups et pour 1: Yeah !.
On sauvegarde et on admire !
Facile non ?
Vous voulez afficher le SOA d’une prob DNS ?
Ce sera :
probe_dns_serial
A vous d’imaginer ensuite vos propres panels.
Vous être chez Let’s Encrypt pour vos certificats ? Vous n’êtes donc pas sans savoir qu’ils ont une durée de 90 jours et doivent donc être renouvelé régulièrement.
Par défaut, Acme.sh (que j’utilise) créé la tâche cron qui va bien et tout roule.
Mais je me suis déjà fait avoir en modifiant une config dans un coin, qui a eu pour effet de bord de modifier un truc qui a modifié un truc, etc… Bref, la renouvellement avait échoué, comme un idiot, je ne l’avais pas vu et je m’en suis rendu compte bêtement en allant sur mon site et en voyant une belle erreur !
Bref, ce serait bien d’avoir un moyen de vérifier cela.
Et ça tombe bien, car à chaque fois qu’une probe de Black Exporter croise un certificat sur son chemin, elle lui pose une question …intime…
Allez dans Grafana, faites une nouvelles requête avec :
probe_ssl_earliest_cert_expiry
Tiens, intéressant ! C’est la date de fin de validité de nos certificats, exprimée en temps Unix.
On va par exemple filtrer sur
probe_success{instance="https://blog.debugo.fr"}
On va passer en mode de visualisation single stat pour avoir la valeur exacte.
On peut connaitre le nombre de seconde restante avec :
probe_ssl_earliest_cert_expiry{instance="https://blog.debugo.fr"} - time()
Pour formater ça de manière lisible, dans Units, sélectionnez Time puis Duration (s). En decimals, vous en mettez 2, et voila !
Ce champ étant disponible à chaque certificat présent, avec la probe SMTP, on obtient donc aussi sa date de fin de validité.
probe_ssl_earliest_cert_expiry{instance="XXX.XXX.XXX.XXX:25",job="SMTP"}
Bien évidement, on peut faire des alertes sur toutes ces informations.
Par exemple, dans un fichier /etc/prometheus/rules/black_alerts.yml :
groups:
- name: black
rules:
- alert: BlackProbe
expr: probe_success == 0
for: 10s
labels:
severity: "critical"
annotations:
summary: "Sur le Job {{ $labels.job }}, il semble que {{ $labels.instance }} ne reponde pas"
- alert: HTTP200
expr: probe_http_status_code != 200
for: 10s
labels:
severity: "critical"
annotations:
summary: "Sur le Job {{ $labels.job }}, il semble que {{ $labels.instance }} ne fonctionne pas correctement"
- name: ssl_expiry
rules:
- alert: SSLCertExpiration
expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 30
for: 1m
labels:
severity: "critical"
annotations:
summary: "Le certificat de {{ $labels.instance }} va expirer dans un mois."
On peut vérifier le fichier avec :
# promtool check rules /etc/prometheus/rules/black_alerts.yml
On peut remettre les permissions :
# chown prometheus:prometheus /etc/prometheus/ -R
Puis on recharge Prometheus :
# curl -X POST http://localhost:9090/-/reload
Et voila pour cette rapide présentation de Blackbox Exporter et de ses possibilités.
L’outil est simple mais se révèle cependant très utile pour monitorer la réponse de services.